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Criteria for Evaluating AAA Protocols for Network Access 
Status of this Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 
Abstract 
This document represents a summary of Authentication, Authorization, 
Accounting (AAA) protocol requirements for network access. In 
creating this document, inputs were taken from documents produced by 
the Network Access Server Requirements Next Generation (NASREQ), 


Roaming Operations (ROAMOPS), and MOBILEIP working groups, as well as 
from TIA 45.6. 
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This document summarizes the requirements collected from those 
sources, separating requirements for authentication, authorization 
and accounting. Details on the requirements are available in the 
original documents. 


1. Introduction 


This document represents a summary of AAA protocol requirements for 


network access. In creating this documents, inputs were taken from 
documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5] 
working groups, as well as from TIA 45.6 [4]. This document 


summarizes the requirements collected from those sources, separating 
requirements for authentication, authorization and accounting. 
Details on the requirements are available in the original documents. 


1.1. Requirements language 


In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 
described in [1]. 


Please note that the requirements specified in this document are to 
be used in evaluating AAA protocol submissions. As such, the 
requirements language refers to capabilities of these protocols; the 
protocol documents will specify whether these features are required, 
recommended, or optional. For example, requiring that a protocol 
support confidentiality is NOT the same thing as requiring that all 
protocol traffic be encrypted. 


A protocol submission is not compliant if it fails to satisfy one or 
more of the MUST or MUST NOT requirements for the capabilities that 
it implements. A protocol submission that satisfies all the MUST, 
MUST NOT, SHOULD and SHOULD NOT requirements for its capabilities is 
said to be "unconditionally compliant"; one that satisfies all the 
MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT 
requirements for its protocols is said to be "conditionally 
compliant." 
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1.2. Terminology 


Accounting 
The act of collecting information on resource usage for the 
purpose of trend analysis, auditing, billing, or cost 
allocation. 


Administrative Domain 
An internet, or a collection of networks, computers, and 
databases under a common administration. Computer entities 
operating in a common administration may be assumed to 
share administratively created security associations. 


Attendant A node designed to provide the service interface between a 
client and the local domain. 


Authentication 
The act of verifying a claimed identity, in the form of a 
pre-existing label from a mutually known name space, as the 
originator of a message (message authentication) or as the 
end-point of a channel (entity authentication). 


Authorization 
The act of determining if a particular right, such as 
access to some resource, can be granted to the presenter of 
a particular credential. 


Billing The act of preparing an invoice. 


Broker A Broker is an entity that is in a different administrative 
domain from both the home AAA server and the local ISP, and 
which provides services, such as facilitating payments 
between the local ISP and home administrative entities. 
There are two different types of brokers; proxy and 
routing. 


Client A node wishing to obtain service from an attendant within 
an administrative domain. 


End-to-End 
End-to-End is the security model that requires that 
security information be able to traverse, and be validated 
even when an AAA message is processed by intermediate nodes 
such as proxies, brokers, etc. 
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Foreign Domain 


An administrative domain, visited by a Mobile IP client, 
and containing the AAA infrastructure needed to carry out 
the necessary operations enabling Mobile IP registrations. 
From the point of view of the foreign agent, the foreign 
domain is the local domain. 


Home Domain 


An administrative domain, containing the network whose 
prefix matches that of a mobile node’s home address, and 
containing the AAA infrastructure needed to carry out the 
necessary operations enabling Mobile IP registrations. 
From the point of view of the home agent, the home domain 
is the local domain. 


Hop-by-hop 


Hop-by-hop is the security model that requires that each 
direct set of peers in a proxy network share a security 
association, and the security information does not traverse 
a AAA entity. 


Inter-domain Accounting 


Inter-domain accounting is the collection of information on 
resource usage of an entity within an administrative 
domain, for use within another administrative domain. In 
inter-domain accounting, accounting packets and session 
records will typically cross administrative boundaries. 


Intra-domain Accounting 


Intra-domain accounting is the collection of information on 
resource within an administrative domain, for use within 
that domain. In intra-domain accounting, accounting 
packets and session records typically do not cross 
administrative boundaries. 


Local Domain 


Proxy 
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An administrative domain containing the AAA infrastructure 
of immediate interest to a Mobile IP client when it is away 
from home. 


A AAA proxy is an entity that acts as both a client anda 
server. When a request is received from a client, the 
proxy acts as a AAA server. When the same request needs to 
be forwarded to another AAA entity, the proxy acts as a AAA 
client. 
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Local Proxy 


A Local Proxy is a AAA server that satisfies the definition 
of a Proxy, and exists within the same administrative 
domain as the network device (e.g., NAS) that issued the 
AAA request. Typically, a local proxy will enforce local 
policies prior to forwarding responses to the network 
devices, and are generally used to multiplex AAA messages 
from a large number of network devices. 


Network Access Identifier 


The Network Access Identifier (NAI) is the userID submitted 
by the client during network access authentication. In 
roaming, the purpose of the NAI is to identify the user as 
well as to assist in the routing of the authentication 
request. The NAI may not necessarily be the same as the 
user’s e-mail address or the user-ID submitted in an 
application layer authentication. 


Routing Broker 


Non-Proxy 


A Routing Broker is a AAA entity that satisfies the 
definition of a Broker, but is NOT in the transmission path 
of AAA messages between the local ISP and the home domain’s 
AAA servers. When a request is received by a Routing 
Broker, information is returned to the AAA requester that 
includes the information necessary for it to be able to 
contact the Home AAA server directly. Certain 
organizations providing Routing Broker services MAY also 
act as a Certificate Authority, allowing the Routing Broker 
to return the certificates necessary for the local ISP and 
the home AAA servers to communicate securely. 


Broker 


A Routing Broker is occasionally referred to as a Non-Proxy 
Broker. 


Proxy Broker 


A Proxy Broker is a AAA entity that satisfies the 
definition of a Broker, and acts as a Transparent Proxy by 
acting as the forwarding agent for all AAA messages between 
the local ISP and the home domain’s AAA servers. 


Real-time Accounting 
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Real-time accounting involves the processing of information 
on resource usage within a defined time window. Time 
constraints are typically imposed in order to limit 
financial risk. 
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Roaming Capability 


Roaming capability can be loosely defined as the ability to 
use any one of multiple Internet service providers (ISPs), 
while maintaining a formal, customer-vendor relationship 
with only one. Examples of cases where roaming capability 
might be required include ISP "confederations" and ISP- 
provided corporate network access support. 


Session record 


A session record represents a summary of the resource 
consumption of a user over the entire session. Accounting 
gateways creating the session record may do so by 
processing interim accounting events. 


Transparent Proxy 


A Transparent Proxy is a AAA server that satisfies the 
definition of a Proxy, but does not enforce any local 
policies (meaning that it does not add, delete or modify 
attributes or modify information within messages it 
forwards). 


2. Requirements Summary 


The AAA protocol evaluation criteria for network access are 
summarized below. For details on the requirements, please consult 
the documents referenced in the footnotes. 
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2.1. General requirements 


These requirements apply to all aspects of AAA and thus are 
considered general requirements. 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 


| General | NASREQ ROAMOPS | MOBILE | 
Reqts. IP 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Scalability | M | M | M | 
| a | 12 | 3 | 30 39 | 
| | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Fail-over | M | | M | 
| b i 42 | | 31 | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Mutual auth M M 
| AAA client/server | 16 | | 30 
| c | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
Transmission level M S 
security 6 31 39 
| d | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Data object | M | M | M | 
| Confidentiality | 26 | 6 | 40 
e 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Data object | M | M | M | 
Integrity 16 6 Bak .39 
f 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | 
| Certificate transport | M | | S/M | 
| g | 42 | |31,33/46 | 
| | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
Reliable AAA transport M M 
mechanism 22 31 32 
h | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Run Over IPv4 | M | ™M | M | 
Lal; 1 33 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | 
| Run Over IPv6 | M | | S | 
| 11 | 1 | 47 | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Support Proxy and | M | | M 
| Routing Brokers | {2 | | 31139 | 
| i | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Auditability S 
| j | 25 | | | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | 
Dual App and Transport O M 
Security not required 6 40 
| k | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | 
| Ability to carry | M | | S 
service-specific attr. 43 3:15:33 
il. 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Key 
M = MUST 
S = SHOULD 
O = MAY 
N = MUST NOT 
B = SHOULD NOT 
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Clarifications 


[a] The AAA protocol must be capable of supporting millions of users 
and tens of thousands of simultaneous requests. The AAA 
architecture and protocol MUST be capable of supporting tens of 
thousands of devices, AAA servers, proxies and brokers. 


[b] In the event of failure to communicate with a given server, the 
protocol must provide a mechanism to change service to another 
backup or secondary server. 


[c] This requirement refers to the ability to support mutual 
authentication between the AAA client and server. 


[d] The AAA protocol requires authentication, integrity protection 
and confidentiality at the transmission layer. This security 
model is also referred to as hop-by-hop security, whereas the 
security is established between two communicating peers. All of 
the security is removed when the AAA message is processed by a 
receiving AAA entity. 


[e] The AAA protocol requires confidentiality at the object level, 
where an object consists of one or more attributes. Object 
level confidentiality implies that only the target AAA entity 
for whom the data is ultimately destined may decrypt the data, 
regardless of the fact that the message may traverse one or more 
intermediate AAA entities (e.g., proxies, brokers). 


[f] The AAA protocol requires authentication and integrity 
protection at the object level, which consists of one or more 
attributes. Object level authentication must be persistent 
across one or more intermediate AAA entity (e.g., proxy, broker, 
etc), meaning that any AAA entity in a proxy chain may verify 
the authentication. This implies that data that is covered by 
object level security CANNOT be modified by intermediate 
servers. 


[g] The AAA protocol MUST be capable of transporting certificates. 
This requirement is intended as an optimization, in lieu of 
requiring that an out-of-band protocol be used to fetch 
certificates. 


[h] This requirement refers to resilience against packet loss, 
including: 


1. Hop-by-hop retransmission and fail-over so that reliability 


does not solely depend on single hop transport 
retransmission. 
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[i] 


[j] 


[k] 


[1] 


Aboba, 


2. Control of the retransmission mechanism by the AAA 
application. 

3. Acknowledgment by the transport that a message was delivered 
successfully, separate from message semantics or syntax 
evaluation. 

5. Piggy-backing of acknowledgments in AAA messages. 

6. Timely delivery of AAA responses. 


In the Mobile IP AAA architecture, brokers can be in the 
forwarding path, in which case they act as transparent proxies 
(proxy brokers). Alternatively, it is also possible to conceive 
of brokers operating as certifying authorities outside of the 
forwarding path (routing brokers). 


An auditable process is one in which it is possible to 
definitively determine what actions have been performed on AAA 
packets as they travel from the home AAA server to the network 
device and back. 


The AAA protocol MUST allow communication to be secured. 
However, the AAA protocol MUST also allow an underlying security 
service (e.g., IP Security) to be used. When the latter is 
used, the former MUST NOT be required. 


The AAA protocol MUST be extensible by third parties (e.g., 
other IETF Working Groups), in order to define attributes that 
are specific to the service being defined. This requirement 
simply means that the AAA protocol MUST allow groups other than 
the AAA WG to define standard attributes. 
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2.2. Authentication Requirements 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | 

| Authentication | NASREQ | ROAMOPS | MOBILE | 
| Regts. | | | IP | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

NAI Support M M S/M 

| a 9 2 32,34,39/| 
| 40 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


+ 
| 
+ 
| 
+ 
l 
+ 
l 
——— 4+ —___. 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
E 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 


| CHAP Support M M 

b 10 3 
tata A S E LEA E I ta tototatatotataota toto totatat 
| | | | | 
| EAP Support | M | S | 
Wi Ne eh RR 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| PAP/Clear-Text Support | M | B | | 
| d | 26 | 3 | | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Re-authentication | M | | S 
| on demand | 17 | | 33 | 
| e | | | | 
toto ta tatr tata tatototatatotatatatototatatotctata tata tota tat 

Authorization Only M 
9 | 


| without Authentication 
| f 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


a 
+ 
| 
+ 
l 
+ 
l 
+ 
| 
+ —— 
l 
+ 
l 
+ 
| 
+ 
l 
+ 
l 
六 二 = 一 
| 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 


Key 

M = MUST 

S = SHOULD 

O = MAY 

N = MUST NOT 

B = SHOULD NOT 


Aboba, et al. Informational [Page 11] 


RFC 2989 Network Access AAA Evaluation Criteria November 2000 


Clarifications 


[a] The AAA protocol MUST allow the use of Network Access 
Identifiers (NAI) [8] to identify users and/or devices. 


[b] The AAA protocol MUST allow CHAP [20] authentication information 
to be transported. This is commonly used by Network Access 
Servers that request authentication of a PPP user. 


[c] The AAA protocol MUST allow for Extensible Authentication 
Protocol (EAP) [14] payload to be transported. Since some EAP 
authentication mechanisms require more than one round trip, the 
AAA protocol must allow for such authentication mechanisms to be 
used. The actual EAP authentication mechanism negotiated MUST 
be transparent to the AAA protocol. When EAP is used, 
authentication typically occurs between the user being 
authenticated and his/her home AAA server. 


[d] While PAP is deprecated, it is still in widespread use for its 
original intended purpose, which is support of clear-text 
passwords. As a result, a AAA protocol will need to be able to 
securely transport clear-text passwords. This includes 
providing for confidentiality of clear-text passwords traveling 
over the wire, as well as protecting against disclosure of 
clear-text passwords to proxies in the forwarding path. 


[e] The AAA protocol MUST allow for a user to be re-authenticated 
on-demand. The protocol MUST allow for this event to be 
triggered by either the user, access device (AAA client), or the 
home or visited AAA server. 


[f] The AAA protocol MUST NOT require that credentials of the user 


be provided during authorization. The AAA protocol supports 
authorization by identification or assertion only. 
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2.3. Authorization Requirements 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | 
| Authorization | NASREQ | ROAMOPS | MOBILE | 
| Regts. | | | IP | 
| | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Static and Dynamic 
IPv4/6 Address Assign. M M M 
| a 11 5 32 36 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


人 
+ 
| 
+ 
l 
+ 
l 
+ 
l 
ET 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
—— e 
l 
+ 
l 
+ 
l 
+ 
l 
+ 
l 
+ 


| RADIUS gateway M M M 
capability 44 3 45 

b 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Reject | M | M | M | 
| capability | 12 | 4 | 39 
| c | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Precludes layer 2 | N | N | 
| tunneling | 11 | 5 | | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Re-Authorization on | M | | S 
| demand | 18 | | 30 33 | 
| d | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Support for Access Rules, M 
| Restrictions, Filters (air ais | | 
| e | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
State Reconciliation M 

f 20 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Unsolicited Disconnect | M | | 

g 18 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


十 


一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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Key 

M = MUST 

S = SHOULD 

O = MAY 

N = MUST NOT 

B = SHOULD NOT 
Clarifications 


[a] The AAA protocol MUST allow a server to provide a static or 
dynamic address during the authorization phase of a user and/or 
device. The address assigned MUST be either of type IPv4 or 
IPv6. If both the client AND the server are aware of a pre- 
configured address, then it is considered static. Anything else 
is dynamic. 


[b] This requirement refers to the ability of a new AAA protocol be 
sufficiently compatible with the large installed base of 
attributes for existing approaches (RADIUS), such that a server 
implementation could speak both protocols, or translate between 
them. 


[c] This requirement refers to the ability of a proxy broker to deny 
access without forwarding the access request to the AAA server, 
or to deny access after receiving an access accept from the AAA 
server. 


[d] This requirement refers to the ability of the AAA client or 
server to trigger re-authorization, or to the ability of the 
server to send updated authorization information to the device, 
such as "stop service." Authorization can allow for a time 
period, then additional authorization can be sought to continue. 
A server can initially authorize a user to connect and receive 
services, but later decide the user is no longer allowed use of 
the service, for example after N minutes. Authorizations can 
have a time limit. Re-authorization does not necessarily imply 
re-authentication. 


[e] This requirement refers to the ability to of the protocol to 
describe access operational limitations and authorization 
restrictions to usage to the NAS which includes (but is not 
limited to): 


Session expirations and Idle Timeouts 
Packet filters 
Static routes 
QoS parameters 


ODP 
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[f] This requirement refers to the ability of the NAS to use the AAA 
server to manage resource allocation state. This capability can 
assist with, but it is not synonymous with, simultaneous user 
login control, port usage limitations, or IP address pooling. 


The design must provide for recovery from data loss due to a 
variety of faults, including NAS and AAA server reboots, and 
NAS/AAA server communication outages, and MUST be independent of 
the accounting stream. The granularity of the recovery of state 
information after an outage may be on the order of a fraction of 
a minute. In order to provide for state recovery, explicit 
session/resource status and update and disconnect messages will 
be required. 


Because of potential multi-domain issues, only systems that 
allocate or use a resource should track its state. 


[g] This requirement refers to the ability of the AAA server to 


request the NAS to disconnect an active session for 
authorization policy reasons. 
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2.4. Accounting Requirements 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | 

| Accounting | NASREQ | ROAMOPS | MOBILE | 
| Reqts. | | | IP | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Real-time accounting M M M 
| a 14 7 31 | 


十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 


et ae 

+ 

l 

+ 

l 

+ 

l 

+ 

l 
——— +. —___. 
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+ 

l 

+ 

l 

+ 

| 

+ 

l 
Es 

l 

+ 

l 

+ 

l 

+ 

l 

+ 

l 

+ 


| Mandatory Compact M | 
Encoding 7 
b 

十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Accounting Record | | M | M | 
| Extensibility | | 7 | 33 | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Batch Accounting | S | | 

| c M il | | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Guaranteed Delivery | M | | M | 
| a | 22 | | 31 | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 

Accounting Time Stamps M M 
| e | 23 | | “40 | 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
Dynamic Accounting M 
f 48 

| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
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Key 

M = MUST 

S = SHOULD 

O = MAY 

N = MUST NOT 
B = SHOULD NOT 
Clarifications 


[a] This requirement may be loosely defined as reporting 
synchronously with events. Typically the time window is on the 
order of seconds, not milliseconds. 


[b] The AAA protocol’s Accounting data format MUST NOT be bloated, 
imposing a large overhead for one or more accounting data 
elements. 


[c] This requirement refers to the ability to buffer or store 
multiple accounting records, and send them together at some 
later time. 


[d] This is an application layer acknowledgment. This is sent when 
the receiving server is willing to take responsibility for the 
message data. 


[e] This requirement refers to the ability to reflect the time of 
occurrence of events such as log-on, logoff, authentication, 
authorization and interim accounting. It also implies the 
ability to provide for unambiguous time-stamps. 


[f] This requirement refers to the ability to account for dynamic 
authentication and authorization. To support this, there can be 
multiple accounting records for a single session. 


2.5. Unique Mobile IP requirements 


In addition to the above requirements, Mobile IP also has the 
following additional requirements: 
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十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
Encoding of Mobile IP M 
registration messages 33 
| | | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Firewall friendly | | | M | 
a 35 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
| | | | | 
| Allocation of local Home | | | S/M | 
| agent | | | 37/41 | 
| | | | 
十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 一 十 
Key 
M = MUST 
S = SHOULD 
O = MAY 
N = MUST NOT 
B = SHOULD NOT 
Clarifications 


[a] A firewall friendly protocol is one which is designed to 
accommodate a firewall acting as a proxy. For example, this 
would permit a Home Agent AAA server situated behind a firewall 
to be reachable from the Internet for the purposes of providing 
AAA services to a Mobile IP Foreign Agent. 


Notes 

[1] Section 4.2.1 of [2] 

[2] Section 4.2.2 of [2]. Also see [8]. 

[3] Section 4.2.3 of [2]. Also see [14]. 
[4] Section 4.2.4 of [2]. 

[5] Section 4.2.5 of [2]. 

[6] Section 4.2.6 of [2]. 

[7] Section 4.3 of [2]. 

[8] Section 6 of [3]. Also see [6]. 

[9] Section 8.2.2.2 of [3]. Also see [14]. 


[10] Section 
[11] Section 


-l of [3]. Also see [14]. 
.2 of [3]. Also see [7]. 
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[12] Section 总 下 外] 二 
[13] Section -4 of [3]. 
[14] Section $2, Of |] 
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[15] Section 8.4.2 of [3]. 
[16] Section 8.1.3 of [3]. 
[17] Section 8.2.1.2 of [3]. 
[18] Section 8.3.1.1 of [3]. 
[19] Section 8.3.2.1 of [3]. Also see [7]. 
[20] Section 8.3.2.3 of [3]. Also see [6], [7]. 
[21] Section 8.4.1.3 of [3]. 
[22] Section 8.4.1.1 of [3]. 
[23] Section 8.4.1.4 of [3]. 
[24] Section 8.4.3.1 of [3]. 
[25] Section 8.4.3.2 of [3]. 
[26] Section 8.2.3.1 of [3]. 
[27] Section 8.3.3.1 of [3]. 
[28] Section 8.1.4.1 of [3]. 
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4. 


Security Considerations 


This document, being a requirements document, does not have any 
security concerns. The security requirements on protocols to be 
evaluated using this document are described in the referenced 
documents. 


IANA Considerations 


This memo does not create any new number spaces for IANA 
administration. 
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has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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